home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group99a.txt
/
000166_icon-group-sender _Tue Jul 27 12:22:12 1999.msg
< prev
next >
Wrap
Internet Message Format
|
2000-09-20
|
10KB
Return-Path: <icon-group-sender>
Received: (from root@localhost)
by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA18656
for icon-group-addresses; Tue, 27 Jul 1999 12:21:44 -0700 (MST)
Message-Id: <199907271921.MAA18656@baskerville.CS.Arizona.EDU>
From: "Frank Lhota" <lhotaf@lexma.meitech.com>
To: <icon-group@optima.CS.Arizona.EDU>
Subject: The Correct Basename Documentation
Date: Tue, 27 Jul 1999 12:31:17 -0400
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO
This is a multi-part message in MIME format.
------=_NextPart_000_0022_01BED82B.EC3433B0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Recently, we have been discussing the basename procedure in the 9.3.2 =
library. It has been noted that the behavior of the procedure has =
changed without any modification in the documentation. There is general =
agreement that either the procedure or the documentation should be =
changed in order to bring them into agreement. Norman Ramsey made a very =
good point regarding this discussion:
A wise man once said, ``If you change the specification of a =
procedure, also change its name.''
In general, I strongly agree with this principle. Identifier names are =
one of the most valuable forms of internal documentation. It is a shame =
that so many programmers treat identifier naming as a second class =
issue. The name of a procedure should express what a procedure does, and =
if the actions of that procedure changes, its name should change to =
express its current actions.
In this case, however, we have a case where the procedure has not =
behaved as its name suggests until recently. The name suggests an =
internal version of the Unix basename utility. The procedure header =
makes this link. Until the 9.3.2 library, however, the basename =
procedure has not behaved the same as its namesake Unix utility. If the =
Unix basename utility is not provided with a suffix, or if the specified =
suffix is not at the end of the name, then basename prints everything =
past the path info. Try this at a Unix command line:
$ basename /usr/icon/ipl/procs/basename.icn .icn
basename
$ basename /usr/icon/ipl/procs/basename.icn
basename.icn
$ basename /usr/icon/ipl/procs/basename.icn .c
basename.icn
In the previous versions of the Icon basename procedure, if the suffix =
was absent or not found at the end, the procedure would lop off both the =
path and everything past the first period. Before the 9.3.2 library, the =
name of this procedure has therefore been misleading.
As a result, the right way to keep basename true to its name is too keep =
its current behavior, that is, matching its Unix namesake. The =
documentation should be updated to reflect this. Here is how =
basename.icn should look:
#########################################################################=
###
#
# File: basename.icn
#
# Subject: Procedures to produce base name of a file
#
# Author: Ralph E. Griswold
#
# Date: September 22, 1998
#
#########################################################################=
###
#
# This file is in the public domain.
#
#########################################################################=
###
#
# Contributor: Charles Shartsis
#
# Updated By: Frank J. Lhota
#
#########################################################################=
###
#
# This procedure is based on the UNIX basename(1) utility. It strips =
off
# any path information. If a suffix is specified, and the stripped name
# ends with the suffix, the suffix will be stripped off too.
#
# It should work under UNIX, MS-DOS, and the Macintosh.
#
#########################################################################=
###
procedure basename(name, suffix) #: base name of file
local base
name ? {
while tab ( upto('/\\:') + 1 ) # get rid of path, if any
if ( base :=3D tab ( -*\suffix ) ) & =3Dsuffix
then return base
else return tab ( 0 )
}
end
------=_NextPart_000_0022_01BED82B.EC3433B0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3401" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Recently, we have been discussing the basename =
procedure in=20
the 9.3.2 library. It has been noted that the behavior of the procedure =
has=20
changed without any modification in the documentation. There is general=20
agreement that either the procedure or the documentation should be =
changed in=20
order to bring them into agreement. Norman Ramsey made a very good point =
regarding this discussion:</FONT></DIV>
<DIV> </DIV>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
<DIV><FONT size=3D2>A wise man once said, ``If you change the =
specification of a=20
procedure, also change its name.''</FONT></DIV></BLOCKQUOTE>
<DIV style=3D"MARGIN-RIGHT: 0px"><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>In general, I strongly agree with this principle. =
Identifier=20
names are one of the most valuable forms of internal documentation. It =
is a=20
shame that so many programmers treat identifier naming as a second class =
issue.=20
The name of a procedure should express what a procedure does, and if the =
actions=20
of that procedure changes, its name should change to express its current =
actions.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>In this case, however, we have a case where the =
procedure has=20
not behaved as its name suggests until recently. The name suggests an =
internal=20
version of the Unix basename utility. The procedure header makes this =
link.=20
Until the 9.3.2 library, however, the basename procedure has not behaved =
the=20
same as its namesake Unix utility. If the Unix basename utility is not =
provided=20
with a suffix, or if the specified suffix is not at the end of the name, =
then=20
basename prints everything past the path info. Try this at a Unix =
command=20
line:</FONT></DIV>
<DIV> </DIV>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
<DIV><FONT face=3D"Courier New" size=3D2>$ basename=20
/usr/icon/ipl/procs/basename.icn .icn</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>basename</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>$ basename=20
/usr/icon/ipl/procs/basename.icn</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>basename.icn</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>$ basename=20
/usr/icon/ipl/procs/basename.icn .c</FONT></DIV>
<DIV><FONT face=3D"Courier New" =
size=3D2>basename.icn</FONT></DIV></BLOCKQUOTE>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>In the previous versions of the Icon basename =
procedure, if=20
the suffix was absent or not found at the end, the procedure would lop =
off both=20
the path and everything past the first period. Before the 9.3.2 =
library,=20
the name of this procedure has therefore been misleading.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>As a result, the right way to keep basename true to =
its name=20
is too keep its current behavior, that is, matching its Unix =
namesake. The=20
documentation should be updated to reflect this. Here is how =
basename.icn should=20
look:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3D"Courier New"=20
size=3D2>################################################################=
############<BR>#<BR># File: =20
basename.icn<BR>#<BR># Subject: Procedures to produce base =
name of a=20
file<BR>#<BR># Author: Ralph E.=20
Griswold<BR>#<BR># Date: September 22,=20
1998<BR>#<BR>############################################################=
################<BR>#<BR># =20
This file is in the public=20
domain.<BR>#<BR>#########################################################=
###################<BR>#<BR># =20
Contributor: Charles Shartsis<BR>#<BR># Updated By: Frank J. =
Lhota<BR>#<BR>###########################################################=
#################<BR>#<BR># =20
This procedure is based on the UNIX basename(1) utility. It strips =
off<BR># any path information. If a suffix is specified, and the =
stripped=20
name<BR># ends with the suffix, the suffix will be stripped off=20
too.<BR>#<BR># It should work under UNIX, MS-DOS, and the=20
Macintosh.<BR>#<BR>######################################################=
######################</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>procedure basename(name, =
suffix) #:=20
base name of file<BR> local base</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2> name ?=20
{<BR> while tab ( upto('/\\:') + 1 ) =
# get=20
rid of path, if any<BR> if ( base :=3D tab =
(=20
-*\suffix ) ) & =
=3Dsuffix<BR> =20
then return base<BR> =
else return=20
tab ( 0 )<BR> }<BR>end<BR></FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV></BODY></HTML>
------=_NextPart_000_0022_01BED82B.EC3433B0--